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The Web service security challenge is to 
understand and assess the risk involved in 
securing a Web-based service today, based 
on our existing security technology, and at 
the same time track emerging standards and 
understand how they will be used to offset the 
risk in new Web services. Any security model 
must illustrate how data can flow through an 
application and network topology to meet the 
requirements defined by the business without 
exposing the data to undue risk. In this paper 
we propose a mechanism for the client to 
provide authentication data, based on the 
service definition, and for the service provider 
to retrieve those data. We also show how 
XML Digital Signatures and encryption can be 
exploited to achieve a level of trust. 


Two terms have emerged for describing loosely coupled 
services delivered over the Internet. These interchangeable 
terms set the stage for a major evolution of application 
and integration styles. The year 2000 is rapidly becoming 
the year in which software services emerged as a viable 
means of flexibly delivering resources to businesses and 
consumers over the Web . .. Two terms, “e-services” and 
“Web services, ” are recognized as describing the phenom¬ 
enon of delivering software as services in the Internet world. 

—Gartner Research Note 1 

To fully support a service model as described by the 
Gartner Research Note, there will also need to be 
a model for security, reliable messaging, quality of 
service, and management for the Web services stack. 
The Web service security challenge is to understand 
and assess the risk involved in securing a Web-based 
service today, based on our existing security tech¬ 
nology, and at the same time track emerging stan¬ 
dards and understand how they will be used to off¬ 


set the risk in new Web services. Any security model 
must illustrate how data can flow through an appli¬ 
cation and network topology to meet the require¬ 
ments defined by the business without exposing the 
data to undue risk. A Web service security model 
must support protocol-independent declarative se¬ 
curity policies that Web service providers can en¬ 
force, and descriptive security policies attached to 
the service definitions that clients can use in order 
to securely access the service. 

Is a Web services security layer really required? The 
industry already has a set of existing and widely ac¬ 
cepted transport-layer security mechanisms for mes¬ 
sage-based architectures, such as SSL (secure sock¬ 
ets layer) and iPSec (Internet Protocol Security); why 
add another? To answer these questions we exam¬ 
ine various components that constitute Web services 
and also explore some possible approaches to secur¬ 
ing Web services. 

Web services 

The Web service paradigm includes a programming 
model for application integration that does not dis¬ 
criminate between applications deployed inside and 
outside the enterprise. Integration and development 
of Web services can be done in an incremental man¬ 
ner, using existing languages and platforms and 
adopting existing legacy applications. However, to 
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achieve a common program-to-program communi¬ 
cation model, it must be built on Web service stan¬ 
dards and communicated over standard protocols. 

IBM’s Web services 2 are intended to complement 
Java** 2 Platform, Enterprise Edition (J2EE**) and 
other standards and allow for a full range of tightly 
coupled distributed and nondistributed applications. 
Web services provide a method to deploy and pro¬ 
vide access to business functions over the Web, and 
J2EE and other traditional programming standards 
are technologies for implementing the provider in¬ 
stance of the Web service. 

One of the anticipated benefits of Web services is 
that direct application-to-application communication 
can replace the human end-user interaction in the 
current data entry Web applications. Web service 
standards have been defined to allow enterprise com¬ 
panies to rapidly define simple business-to-business 
interfaces and exchange messages. Additional re¬ 
quirements for a Web services infrastructure include 
support for service context, conversations and activ¬ 
ities, intermediaries, portal integration, and work- 
flow and service flow management. 

XML. Extensible Markup Language (xml) 3 began 
as an extensible data format to address the limita¬ 
tions of HTML (HyperText Markup Language), but 
has become a standard for communication between 
applications. With XML, an application defines 
markup tags to represent the different elements of 
data in a text file so that the data can be read and 
processed by any application that uses XML. 

Using XML, it is possible for business persons to de¬ 
fine policies and express them as xml documents. 
These documents can have sections that are en¬ 
crypted and the documents themselves can be dig¬ 
itally signed, distributed, and then interpreted by the 
security mechanisms that configure the local soft¬ 
ware. This allows various implementations to map 
from the XML description to a local platform-spe¬ 
cific policy enforcement mechanism without requir¬ 
ing changes to the infrastructure. 4 

SOAP. Simple Object Access Protocol (soap) 5 is a 
simple, lightweight, and extendable XML-based mech¬ 
anism for exchanging structured data between net¬ 
work applications on top of widely used Internet stan¬ 
dards such as xml and http (HyperText Transfer 
Protocol). SOAP consists of three parts: an envelope 
that defines a framework for describing the contents 
of a message, a set of encoding rules for expressing 


instances of application-defined data types, and a 
convention for representing remote procedure calls 
(rpc) and responses. SOAP can be used in combina¬ 
tion with a variety of network protocols such as HTTP, 
RMI/IIOP** (Remote Method Invocation/Internet In- 
ter-ORB** [Object Request Broker] Protocol), SMTP 
(Simple Mail Transfer Protocol), ftp (File Transfer 
Protocol), or MQ (Message Queuing). 

SOAP can potentially be used in combination with a 
variety of other protocols; however, the only bind¬ 
ings we discuss here are SOAP in combination with 
HTTP and HTTP Extension Framework. 6 The usage 
of a particular protocol does not change the funda¬ 
mentals of the security model but may change the 
particular implementation. 

The SOAP envelope is defined in xml and enables 
a large variety of meta-information to be added to 
the message, such as transaction identifiers, message 
routing information, and message security. The en¬ 
velope consists of two parts: header and body. The 
header is a generic mechanism for adding features 
to a SOAP message. All immediate child elements of 
the SOAP header element are called header entries. 
The body is a container for application data intended 
for the ultimate recipient of the message. Thus, SOAP 
can be considered as another layer, between the 
transport layer (e.g., HTTP) and the application layer 
(e.g., business data), that is a convenient place for 
conveying message meta-information. 

WSDL. Web Services Description Language (wsdl) 7 
is essentially an XML IDL (interface definition lan¬ 
guage) that provides a way to describe the function 
and interface of a service. It is a format for describ¬ 
ing network services as a set of endpoints operating 
on messages containing either document-oriented 
or procedure-oriented information. The operations 
and messages are described abstractly, and then 
bound to a concrete network protocol and message 
format to define an endpoint. Related concrete end¬ 
points are combined into abstract endpoints (ser¬ 
vices). WSDL is extensible to allow description of end¬ 
points and their messages regardless of what message 
formats or network protocols are used to commu¬ 
nicate; however, the only currently described bind¬ 
ings are for soap 1.1, http get/post, and mime 
(Multipurpose Internet Mail Extensions). 

The WSDL service information can be extracted from 
a UDDI (Universal Description, Discovery, and In¬ 
tegration 8 ) business service entry, or maybe obtained 
from other service repository sources. 
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Regardless of the source, both run-time and devel¬ 
opment tools can use WSDL to determine run-time 
bindings to a service. This information can be used 
to build the logic to access the service either directly 
from the client or through generated code stubs. 

WSDL has the potential to be extended 9 to include 
the definition of the context needed by the business 
execution environment, including security. Without 
these extensions, users will make assumptions about 
security in the run-time environment of a Web ser¬ 
vice. Defining these security assertions in XML will 
allow us to have a common interpretation of secur¬ 
ity attributes in different implementations. It will also 
facilitate searching. 

Secure Web services 

There are fundamental business reasons underlying 
the existence of various security mechanisms. The 
authentication of the entity asserting an identity when 
requesting a service allows businesses to offer dif¬ 
ferent classes of service to different customers. The 
business reason for data integrity is to ensure that each 
party in a transaction can have confidence in the bus¬ 
iness transaction. There is also a business and legal 
need to have an audit trail and some evidence of non¬ 
repudiation to address liability issues. And more and 
more businesses are becoming aware of the internal 
threats to their applications by employees or others 
inside the firewall. Some business transactions re¬ 
quire that confidentiality be provided on a service in¬ 
vocation or its data (such as credit card numbers). 
Also businesses on the Internet need to protect them¬ 
selves from denial-of-service attacks. This is the envi¬ 
ronment in which we need to provide a security ser¬ 
vice model. 

Moving forward from prototypes of Web services will 
require an open security service model, based on 
standards, that can serve a heterogeneous “trust do¬ 
main.” This security model should support interfaces 
for security services that: 

1. Use xml data formats as the common represen¬ 
tation of various security assertions 

2. Accept policy information expressed in XML to 
configure services (extending WSDL) 

3. Use xml messaging as the secure mechanism for 
exchanging the XML security assertions and also 
for servicing Web service requests 

Security technologies. To evolve from existing ap¬ 
plications will initially involve wrapping legacy code 


with Web services. Some of the security constraints 
and trust models of existing applications will need 
to be carried forward and expressed within the early 
versions of Web services. To accomplish this we will 


Some of the security constraints 

of existing applications will need 
to be carried forward in early 

versions of Web services. 


need to incorporate the work begun, in the various 
Web services toolkits, on security technology from 
basic authentication to XML digital signature support. 

As these security technologies themselves become 
services, and workflow becomes the primary appli¬ 
cation paradigm for dynamic application integration, 
security services will evolve into core elements of a 
secure application workflow. 

A variety of security technologies are being adopted 
as standards. Following is a brief overview of these 
standards and how they can be used. 

XML Digital Signatures 10 is a standard for securely ver¬ 
ifying the origins of messages. The XML signature 
specification allows xml documents to be signed in 
a standard way, with a variety of different digital sig¬ 
nature algorithms. Digital signatures can be used for 
validation of messages and for nonrepudiation. 

Security Assertion Markup Language 11 is the first in¬ 
dustry standard for secure e-commerce transactions 
using XML. SAML is being developed to provide a 
common language for sharing security services be¬ 
tween companies engaged in business-to-business 
and business-to-consumer transactions. SAML allows 
companies to securely exchange authentication, au¬ 
thorization, and profile information between their 
customers, partners, or suppliers regardless of their 
security systems or e-commerce platforms. As a re¬ 
sult SAML promotes the interoperability between dis¬ 
parate security systems, providing the framework for 
secure e-business transactions across company 
boundaries. 

XML Encryption 12 will allow encryption of digital con¬ 
tent, such as Graphical Interchange Format (gif) 
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images, Scalable Vector Graphics (SVG) images, or 
xml fragments, xml Encryption allows the parts of 
an XML document to be encrypted while leaving 
other parts open, encryption of the XML itself, or the 
superencryption of data (i.e., encrypting an XML doc¬ 
ument when some elements have already been en¬ 
crypted). 

As part of the Java Community Process (JCP), there 
are two Java specification requests (JSRs) that are 
currently in progress; JSR105 XML Digital Signature 13 
and JSR106 XML Digital Encryption. 14 When com¬ 
plete, these two JSRs will define the standards in Java 
for each technology, thus standardizing the interfaces 
in each vendor’s Web services toolkit. 

Application patterns 

Patterns are available for evolving to Web services 
from existing Web server applications. One is the 
browser-to server-pattern. This pattern wraps an ex¬ 
isting application as a service, using a SOAP message 
as the service invocation. The Web server provides 
a run-time execution container that defines its own 
security model, with policy information derived from 
a deployment descriptor configured by the deployer 
of the Web server application. This pattern typically 
includes a mechanism for associating the identity of 
the invoking entity (the browser client) with the ex¬ 
ecuting application instance, and allows the appli¬ 
cation to continue to function as it did before. With 
J2EE, an identity is provided as part of authentica¬ 
tion, and the container associates that identity to the 
security context. This pattern uses an implicit trust 
model in the sense that the client and the server rely 
on the middleware configuration to ensure that the 
identity is established within a security context pro¬ 
vided by J2EE itself. An advantage of this model is 
that the run-time code maintains the identity map¬ 
ping, and name assertion life-time constraints and 
mechanisms for maintaining a valid token can be pro¬ 
vided by the middleware. One of the disadvantages 
is that the model for “delegating” an identity requires 
that the delegated application-level identity is the 
same as the invocation identity of the intermediary 
(and hence the security context). This creates a cou¬ 
pling between middleware and the application-level 
delegation logic (i.e., run-as element in J2EE) and the 
requirement for the security context to support cas¬ 
caded delegation, auditing, and nonrepudiation. 

Another pattern involves rewriting the application 
with a modular design to create smaller tasks that 
can be combined in different ways to perform more 


complicated transactions. Each component is able 
to externalize its output into a message that the next 
component can use as input. This pattern uses SOAP 
messages to trigger each event. The messaging agents 
and message queues can be built into the run-time 
server below the application level. Sometimes the 
messaging agents become the “security-aware” part 
of the run-time code and control the flow of infor¬ 
mation along its path through components based on 
security attributes in the header of the message. 
Sometimes the security attributes get added into the 
message structure itself, as is the case with digital 
signatures. The trust model for this type of messag¬ 
ing relies on the specification of an explicit trust 
model along the lines of SAML. In the SAML-type 
name assertion, the trust will be explicit 15 in the sense 
that the client and the server rely on coupling the 
identity information explicitly with the message, 
rather than on the underlying security context. Of 
course, this requires that the service handler be able 
to establish the identity of the caller based on the 
SAML-type name assertions and on trusting the entity 
that created these assertion tokens. Thus in a SAML 
trust model, an authentication/authorization author¬ 
ity has to be known and to digitally sign the assertions at 
the time of the authentication/authorization event. A 
certificate associated with the signature can be used 
to identify the trusted authority and validate the sig¬ 
nature, and a time stamp is included to indicate the 
assertion validity period. An advantage of this type 
of trust model is that the message can pass through 
multiple intermediaries. Authorization and delega¬ 
tion decisions can be made in a standard way by the 
intermediaries without modifying the name asser¬ 
tion of the originator of the message request. If im¬ 
plemented in an “envelope,” it is also possible to 
build audit trails capable of asserting evidence of 
nonrepudiation, since each intermediary could wrap 
a message with its own name assertion. A disadvan¬ 
tage of this model is that the last component has to 
do some additional processing to make sure that the 
originator name assertion is valid from both a trust 
and a time standpoint. 

Both these patterns implement security in the run¬ 
time code and both rely on a mapping of an external 
form of an identity into a run-time interpretation of 
that identity and into a set of rules about the iden¬ 
tity and its capabilities. The difference has to do with 
where the mapping is done and whether the infor¬ 
mation is in an externalized form that can be middle- 
ware-independent and persistent. 
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Figure 1 Usage scenario 


TRAVEL AGENCY SERVICES 


AIRLINE SERVICES 


http://hostname/agencyServices 
POST /TravelService HTTP/1.1 

<SOAP-ENV:Body> 

<m:makeReservation xmlns:m="some-URI"> 
<flight>ABC 1234</flight> ... 
</m:makeReservation> 

</SOAP-ENV:Body> 



<SOAP-EN V: Body> 

<m: reservation Response xmlns:m="Some-URI"> 
<confirmNo>ABCXYZ123</confirmNo> 

</m: reservation Response> 

</SOAP-ENV:Body> 

◄- 



POST /AirlineService HTTP/1.1 

<SOAP-ENV:Body> 

<m:booking xmlns:m="some-URr , > 
<flight>1234</flight>... 
</m:booking> 

</SOAP-ENV:Body> 


► 


<SOAP-ENV:Body> 

<m:bookingResponse xmlns: 
m="Some-URI"> 
<recordLocator>ABCXYZ123 
</recordLocator> 
</m:bookingResponse> 
</SOAP-ENV:Body> 

◄- 



A usage scenario 

Consider a very simple scenario: a travel agency sys¬ 
tem contacts an airline reservation system in order 
to complete a travel transaction request (see Figure 
1). The two applications, Web services for a travel 
agency and an airline, use xml to exchange travel 
itinerary information and payment details, using a 
well-understood industry standard specification. The 
specification requires that applications mark reser¬ 
vations with the <makeReservation> tag. 

The travel agency’s application is designed to accept 
a reservation request with a <makeReservation> 
tag from a customer. Based on the airline details re¬ 
quested, the application will contact the airline’s res¬ 
ervation service. The airline’s application is designed 
to perform a transaction under which a reservation 
for the passenger is made and charged to the credit 
card system. Note that the airline can even contact 
the credit card company’s charging service in order 
to perform that operation. 


A user searches for the best possible travel deal 
and decides to purchase the ticket from our travel 
agency. The user submits a request to access the 
agency’s reservation Web service by specifying the 
itinerary and credit card details in a SOAP message 
marked with a <makeReservation> tag. The 
agency application requests a reservation to be 
made to the airline reservation system by sending 
a booking request, providing the agency’s details 
and the passenger details. When the airline sys¬ 
tem receives the booking request, the application 
queries the database for the availability of seats 
for that particular itinerary. Using XML, the air¬ 
line application returns a response after making the 
reservation in its back-end system. The response 
marks the details with record locator number as 
<recordLocator>ABCXYZ123</recordLocator>. 
When the travel agency receives the message from air¬ 
line, the application scans it for the <recordLocator> 
tag, and upon finding it passes the data into its system 
to issue a ticket to the end user. 
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The Web service that provides reservation service 
in a service network can be combined with other ser¬ 
vices, such as a service to obtain weather informa¬ 
tion for the travel destination and a credit service 
to charge the end user for the travel expense. This 
way the travel agency can automatically issue tickets 
and schedule ticket delivery with shipping compa¬ 
nies through their Web services. 

This example describes a simple Web service where 
two or more functions cooperate through the Web, 
and the nature of their cooperation adapts to pa¬ 
rameters provided by a particular request. As we see, 
Web services provide a framework for loosely cou¬ 
pled (dynamic) application integration. 

Web service provider security 

In the previous example we described how loosely 
coupled applications can be combined to provide a 
Web service-based e-business solution. Users can in¬ 
voke Web services using one of the supported pro¬ 
tocols. For example, users can submit SOAP requests 
over http to be processed by the Web service en¬ 
gine. When Web services are used to provide busi¬ 
ness-related data, those data need to be secured. 

The Web application server that hosts the Web ser¬ 
vice engines can support various protocols. Some¬ 
times, due to the bundling of security with protocols, 
tasks need to be categorized for performance as ei¬ 
ther protocol-specific or as protocol-neutral secur¬ 
ity tasks. A transport protocol-specific handler per¬ 
forms security tasks such as SAML authentication or 
identity assertions when the authentication informa¬ 
tion is passed as part of the transport protocol, 
whereas a transport protocol-neutral authorization 
handler can perform authorization based on this au¬ 
thentication information regardless of the transport. 
Once the user is authenticated, the Web service se¬ 
curity provider should determine if the invoking user 
has the authority to invoke the service. This autho¬ 
rization decision is based on the authorization pol¬ 
icy associated with the Web service. 

Authentication 

In order to secure access to a Web service, the user 
requesting the service needs to be identified through 
underlying authentication mechanisms (see Figure 
2 ). 

Authenticating the user. An identity needs to be as¬ 
sociated with a request in order to enforce autho¬ 


rization policies. A Web service security configura¬ 
tion should specify authentication policies that define 
how the user credential (or authentication data) is 
to be retrieved as well as how it is to be verified. In 
the J2EE security model, the log-in configuration pol¬ 
icy specifies how user information is to be retrieved 
(e.g., HTTP Basic) and the operational environment- 
specific policies will dictate how it gets authenticated 
(e.g., Kerberos authentication mechanism). In the 


A user may be authenticated 

by the Web service engine, 
or before the Web service engine 
is given the request. 


Web service security model, the log-in configuration 
should not only address authentication of immedi¬ 
ate clients (clients submitting the request directly to 
the service), but also address indirect clients (an end 
client’s identity may be part of the request, which 
can traverse through many intermediaries). This in¬ 
formation is necessary for both the client (to submit 
the credential information in a format understood 
by the server) and the server (to retrieve the creden¬ 
tial information from the transport layer or the mes¬ 
sage itself). 

The WSDL definition of the service will include se¬ 
curity constraints on how the credential information 
is expected to be provided (or retrieved). For exam¬ 
ple, in the case of an HTTP-bound service, data are 
expected to be supplied through HTTP Basic authen¬ 
tication. In the case of a service that can be accessed 
through an intermediary, the WSDL definition should 
indicate that the credential information is expected 
as part of the message itself. For example, it could 
say that the authentication information is expected 
in the “SOAP-SEC: SecurityToken” header. 16 Based 
on these two possibilities, we could state that authenti¬ 
cation data are supplied using either a transport-spe¬ 
cific mechanism (e.g., HTTP Basic), or transport-neu¬ 
tral mechanism (e.g., SOAP-SEC) header but not both. 

Depending on the network topology, a user may be 
authenticated by the Web service engine or before 
the Web service engine is given the request. For ex¬ 
ample, when a user submits a request to the servlet 
that dispatches the Web service request, the user 
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Figure 2 Web service authentication 
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might be challenged by a front-end reverse proxy 
server, using the HTTP 401 challenge mechanism, so 
that the user can submit his or her credentials (user 
identifier and password). 

In order to handle the authentication data that get 
passed around through different means, a Web ser¬ 
vice engine will use transport-specific handlers as well 
as transport-neutral handlers. For example, in a J2EE 
environment where HTTP is the transport protocol 
used, the HTTP-specific handler (i.e., servlet) can in¬ 
voke the getUserPrincipal API (application program¬ 
ming interface) to retrieve the identity of the user. 
If the user is not already authenticated as far as the 
underlying system is concerned, the handler should 
authenticate the user based on the credentials sent 


over the transport (e.g., user identifier and password 
in the HTTP header). This transport-dependent ap¬ 
proach to perform authentication will allow the au¬ 
thorization and downstream processing of the call 
to be transport-neutral. If identity information is 
present in the message itself, the security handler 
will retrieve those data and validate the information. 

Asserting the user identity. Once authenticated, the 
identity of the user must be securely associated with 
the context of execution to be used in the down¬ 
stream requests. To do so, the authentication han¬ 
dler asserts the identity of the user within the request. 
For example, a special header, containing the as¬ 
serted identity of the user, digitally signed by the se¬ 
curity service, can be attached to the request. The 
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Figure 3 Authorization scenario 
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user name could be replaced by the Kerberos cre¬ 
dential of the user. By establishing the user identity 
within the execution context, the Web service run¬ 
time component (e.g., J2EE container) can perform 
authorization based on the user identity. 

For example, a J2EE application server can challenge 
user “Bob” when he tries to access a Web service. 
When the Web service is invoked, the HTTP security 
handler will call the getUserPrincipal routine to val¬ 
idate “Bob.” In the case of a SOAP binding, the au¬ 
thentication handler may insert a “SOAP-SEC: Se- 
curityToken Bob” header asserting that the calling 
principal is “Bob.” 

Authorization enforcement 

Based on the authorization policies specified for the 
services, the J2EE container will enforce the autho¬ 
rization policies. For example, user Bob would be 
allowed to access our travel agency service only if he 
is authorized to do so. 

In order for the Web service provider to enforce se¬ 
curity constraints on Web services, the security pol¬ 


icies must be declaratively conveyed to the run-time 
authorization policy endpoint to ensure portability 
of the service from one Web application server to 
another. One approach is for the service provider in¬ 
frastructure to take care of defining the security pol¬ 
icies. Then the Web service developers need not know 
how to programmatically enforce all possible autho¬ 
rization policies for the different servers in which the 
service may be deployed. 

In order to maintain a level of abstraction of pol¬ 
icies during service installation and to give the abil¬ 
ity to specify application security policies during Web 
service development, Web service security policies 
should be expressed in terms of roles. As in J2EE, a 
security role is a semantic grouping of permissions 
that a given type of user must have in order to suc¬ 
cessfully use the Web. 

As shown in Figure 3, a user who is a registered cus¬ 
tomer to our travel agency is granted the permission 
to make travel reservations using a travel service. 

In order for an authorization check to succeed, the 
user invoking the service must have at least one of 
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Table 1 Principal role-mapping example 


Subjects 


Roles 



Clerk 

Customer 

Supervisor 

AdminGroup 

CustomerGroup 

X 

X 


GoldCustomers 


X 


ManagerGroup 

Bob 

X 

X 

X 


the roles required to access the service. The mech¬ 
anisms by which users and user groups are granted 
application roles are specific to the operational envi¬ 
ronment. 

As shown in Figure 3 and Table 1, the makeReser- 
vation method on the travel agency Web service re¬ 
quires the role “Customer.” For example, if user Bob 
makes a request, his identity is associated with the 
context of execution. The security run-time compo¬ 
nent will make the authorization decision based on 
the identity of the caller invoking the service. The 
ability to specify authorization policy declaratively 
helps decouple the application security policy from 
organizational security policies, while still effectively 
enforcing overall security requirements. 

Trust. The IETF (Internet Engineering Security Task 
Force) security glossary 17 contains several definitions 
of trust. One of them asserts: “Generally, an entity 
can be said to ‘trust’ a second entity when it (the first 
entity) makes the assumption that the second entity 
will behave exactly as the first entity expects. This 
trust may apply only for some specific function.” 

Trust is emerging as one of the central issues of all 
communications in the Internet age. How do we eval¬ 
uate and find that which is trustworthy and discard 
that which is not? Trust in itself is a very fuzzy con¬ 
cept. There are ways in which we implicitly trust, such 
as trusting friends to help if your car breaks down, 
or explicitly trust, such as contracting for work to be 
done on your house. The evolution of XML-based 
vocabularies for e-commerce raises the question of 
how the trust in these new documents will be defined 
and enforced. 

XML Digital Signatures offer an interesting frame¬ 
work for working with this question. Individuals cre¬ 
ate signatures that can be applied to “any digital con¬ 
tent (data object).” Digital signatures can provide 


integrity, signature assurance, and in some cases ev¬ 
idence of nonrepudiation of Web data. This is es¬ 
pecially important for documents that represent 
commitments, such as contracts, price lists, and man¬ 
ifests. The work on XML Digital Signatures addresses 
the digital signing of documents (any Web resource 
addressable by a uniform resource indicator [URl]) 
using XML syntax. This capability is critical for a va¬ 
riety of electronic commerce applications, including 
tools for payment. 

The W3C XML DSIG specification 10 addresses the sign¬ 
ing of parts of an xml document as well as the en¬ 
tire document. When combined with SOAP (as rec¬ 
ommended to the W3C by IBM and Microsoft) 16 
xml DSIG can be used by the sender of the message 
to generate a signature over the body of the SOAP 
message. The receiver is able to parse the signature 
element in the SOAP header and either extract the 
certificate needed to verify the signature from the 
message itself, or find a reference to a key 18 that was 
used to sign the body of the SOAP message. 

Establishing trust. When a Web service delegates 
part of its work to another service, it may establish 
a broad mutual trust relationship, or it might need 
to establish trust on every request submitted. In any 
kind of trust relationship, there can be different lev¬ 
els of granularity at which a request (or response) 
needs to have trust asserted. In a paper-based work- 
flow, it may be sufficient to seal and sign the letter 
envelope that contains many documents. Similarly, 
in a Web services-based workflow, it may be suffi¬ 
cient to sign the SOAP header to assert that the doc¬ 
uments attached to the SOAP body can be trusted and 
are not tampered with. 

Web services can use the xml digital signature ca¬ 
pability in different ways to achieve different levels 
of trust. In our previous example, the travel agency 
and the airline establish a broad mutual trust rela¬ 
tionship and agree to digitally sign requests and re¬ 
sponses. The SOAP engine used by the travel agency 
signs the request and sends it across the HTTPS (HTTP 
over SSL) connection. The request may contain sev¬ 
eral documents. Figure 4 illustrates an example of 
how XML DSIG is used to sign a request to issue tick¬ 
ets. 

If the two entities involved in this trust relationship 
were concerned about internal security, additional 
trust, including the signing of individual documents 
or fields and not just the envelope, may be required. 
The two entities may also require that all requests 
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Figure 4 Travel service example 


<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 
<SOAP-EN V: Header> 

<SOAP-SEC:Signature 

xmls:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"> 

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 

<ds:Reference URI="#BODY"../> 

<ds:Signature> 

<SOAP-SEC:Signature> 

<SOAP-EN V: Header> 

<SOAP-ENV:Body xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" 
SOAP-SEC:id="Body"> 

<m:lssueTickets xmlns:m="some-URr i > 

<m:company>Travel-R-Us</m:company> 

<m:ticketholder>Joe Someone</m:ticketholder> 
<m:customerCC>Visa</m:customerCC> 

<m:CC#>111 -222-3333</m:CC#> 

</m:lssueTickets 
</SOAP-EN V: Body> 

</SOAP-EN V: Envelope> 


contain encrypted data elements, 12 such as credit 
card number, as well as signed elements. In this ap¬ 
proach, even if the individual documents are ex¬ 
tracted from the envelope and used later in a dif¬ 
ferent context (e.g., stored for later reference), the 
documents contain persistent security attributes, 
which can be verified at any time. In a paper-based 
workflow, this would be the equivalent of requiring 
that individual letters in an envelope be signed. 

Figure 5 illustrates how XML DSIG could be used by 
the airline to sign each “IssueTicket” content of the 
response it sends to the travel agency. In this sce¬ 
nario, the xml element, not the SOAP message or 
body, is the object of the signature. In addition to 
these signed data, the two companies would prob¬ 
ably need to use the https protocol to provide a se¬ 
cure authenticated communication channel over 
which these signed xml elements can be exchanged. 

A further evolution of a simple travel workflow sce¬ 
nario would be possible if the travel industry defines 


standard xml elements (like signed Ticket elements) 
and a distributed workflow to replace current point- 
to-point implementations as in this example. 19 

Trusted third parties. If there are only two parties 
engaged in an exchange, a trust relationship can be 
established between them. However, as Web services 
enable the discovery of and dynamic binding to new 
partners, a third-party trust relationship may be 
needed. Two entities involved in a contract may not 
know each other but may each trust a common third 
party. In such cases, they may want the third party 
to be the one to sign and verify that the other party 
is trustworthy. In a paper-based workflow, a neutral 
third party or notary may be needed as a witness to 
a transaction. Similarly, in a Web services environ¬ 
ment, a third party may be required to assert the va¬ 
lidity of a request, or a response, or even the cre¬ 
dentials of the requestor or the target. 

In the previous example above, both the travel agency 
and the airline might agree to use public key cer- 


IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002 


HONDO, NAGARATNAM, AND NADALIN 237 





Figure 5 Data signing example 


<Signature ld="Travel-R-Us01" xmlns="http://www.w3.org/2000/09/xmldsig#"> 

<Signedlnfo> 

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/> 
<SignatureMethod Algorithm^' http://www.w3.Org/2000/09/xmldsig#dsa-sha1 "/> 

<Reference URI="#lssueTicket" /> 

<Transforms> 

<Transform Algorithm^'http://www.w3.org/TR/2000/CR-xml-c1 4n-20001026"/> 
</Transforms> 

<DigestMethod Algorithm="http://www.w3.Org/2000/09/xmldsig#sha1 "/> 
<DigestValue>YWJjZGxma3NqamRIZmZnaGlvcztkbGZramFzZGw7Cg==</DigestValue> 
</Reference> 

</Signedlnfo> 

<SignatureValue>YWJjZGxma3NqamZmZnaGlvcztkbGZramFzZGw7Cg==</SigntureValue> 

< Key Info 
<KeyValue> 

<DSAKeyValue> 

<P>...</P><Q>...</Q><G>...</GxY>...</Y> 

</DSAKeyValue> 

</KeyValue> 

</Keylnfo> 

</Signature> 

<lssueTicket> 

<PassengerName>...</> 

<ShippingAddress>...</> 

<Billinglnfo>...</> 

</lssueTicket> 


tificates and key pairs generated by a trusted third 
party, a “travel better business bureau.” In this pat¬ 
tern, each party checks that the other is a legitimate 
member of this trust domain by contacting the third 
party, which could perform an on-line validation 20 
of the certificates for certified travel businesses as 
a value-added Web service. Once the travel agent 
gets the okay from the travel better business bureau, 
it accepts the signed requests of the airline. 

Auditing and nonrepudiation 

An audit capability can capture a tamper-resistant 
record of security-related events in order to evalu¬ 
ate the effectiveness of security policies and mech¬ 
anisms. This paper does not discuss requirements for 
auditing security-relevant events in Web services, or 
APIs for Web service containers to generate audit rec¬ 
ords. A future version of the Web services security 
specification may include such requirements. 


Nonrepudiation as a legal term implies providing le¬ 
gal evidence that a user performed some action, such 
that the user cannot reasonably deny having done 
so. In some cases, it is claimed that XML Digital Sig¬ 
natures can be used to provide signed evidence of 
the xml messages exchanged between the services. 
But an end-to-end solution to nonrepudiation is a 
difficult problem and involves trust issues. Therefore, 
this paper does not propose a solution for non¬ 
repudiation, which should be addressed in the 
future. 

Summary 

A Web service security model should address secur¬ 
ity issues involved in a request from an end client 
to a target service, including the intermediary ser¬ 
vices that route the service requests. This paper pro¬ 
poses a mechanism for the client to provide authen¬ 
tication data based on the service definition and, at 
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the same time, for the service provider to retrieve 
those data. 

Because of the necessity for and complexity in es¬ 
tablished trust in the Web services model, this pa¬ 
per also proposes how xml Digital Signatures and 
encryption can be exploited to achieve a level of trust. 
We show that as part of its evolution, the Web ser¬ 
vices requirements for application development can 
be seen as an opportunity to introduce a method of 
coupling security technologies (authentication, au¬ 
thorization, digital signatures, etc.) with business 
trust issues (public key infrastructure policy, role- 
based access control, firewalls, etc.) and workflow 
into the creation of core Web security services con¬ 
figured through policies expressed in XML. 

As the base Web service technology evolves, more 
complex scenarios need to be considered and han¬ 
dled in the future. 

Future 

As we begin to secure Web services, we can also eval¬ 
uate service offerings through the perspective of risk 
assessment. No Web service is impenetrable to at¬ 
tack. Every offering of a service implies risk, whether 
on the Internet or on an intranet, because there is 
always a risk when a service interface is externally 
exposed. The question is: what is the scope of the 
exposure, how can the exposure be offset by the po¬ 
tential value of the service, and who is responsible 
for the enforcement of any countermeasures 
used to prevent the service interface from being 
exploited? 

The ability to supply a complete Web service envi¬ 
ronment, in which risk assessment and policy en¬ 
forcement are an integral component, will depend 
on several initiatives continuing to evolve as de facto 
standards. First, the workflow needs an integrated 
security model as part of its processing model. Sec¬ 
ond, analysis is needed to determine whether XML 
schemas can be used to formalize security models 
through the definition of security types. Third, Web 
Services Description Language, Web Services Flow 
Language, 21 or Web Services Endpoint Language 
need to be extended to contain security attributes 
and policy information related to Web services. In 
particular, the specification of PKI policies will be im¬ 
portant for interoperability in the more dynamic Web 
services involving late binding. Finally, the emerg¬ 
ing W3C activities to define the processing rules and 


key management services for XML applications must 
be well integrated with the other Web services spec¬ 
ifications. 


Appendix A: Glossary 

access To access is to interact with a system entity in order to 
manipulate, use, gain knowledge of, or obtain a representation 
of, some (or all) of a system entity’s resources. 

access control Access control protects resources against unau¬ 
thorized access; it is a process by which use of resources is reg¬ 
ulated according to a security policy and is permitted by only au¬ 
thorized system entities according to that policy. 

assertion An assertion is data, produced by a SAML authority, 
constituting a declaration of identity, or attribute information, 
or authorizations. 

asserting party Formally, an asserting party is the administrative 
domain hosting SAML authorities that are issuing assertions. In¬ 
formally, it is an instance of an assertion-issuing SAML author¬ 
ity. 

attribute An attribute is a distinct characteristic of an object. An 
object’s attributes are said to describe the object. Objects’ at¬ 
tributes are often specified in terms of their physical traits, such 
as size, shape, weight, and color, etc. for real-world objects. Ob¬ 
jects in cyberspace might have attributes describing size, type of 
encoding, network address, etc. Which of the object’s attributes 
are salient is decided by the observer. 

attribute assertion An attribute assertion declares that the spec¬ 
ified subject has the specified attribute(s). Attributes maybe spec¬ 
ified by means of a URI (uniform resource indicator) or through 
an extension schema that defines structured attributes. 

authorization assertion An authorization assertion declares that 
a subject has been granted specific permission to access one or 
more resources. 

credential A credential is information that is transferred to es¬ 
tablish a claimed principal identity. 

decision assertion A decision assertion reports the result of the 
specified authorization request. 

group A group names a collection of principals to which permis¬ 
sions may be granted. 

permission Permission refers to a set of activities (a set of one 
or more operations on some set of one or more resources) that 
is the target of an authorization decision. 

principal A principal is a system entity; its identity can be au¬ 
thenticated. 

principal identity A principal identity is a way to represent a prin¬ 
cipal’s identity, typically an identifier. 

relying party A system entity that is making a decision contin¬ 
gent upon information or advice from another system entity is 
a relying party; e.g., a system entity that is relying upon various 
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SAML assertions about some other party(ies), made by yet other 
party(ies). 

role A role is a set of permissions that may be granted to a prin¬ 
cipal. 

security assertion A security assertion is typically scrutinized in 
the context of a security policy. 

Security Assertion Markup Language (SAML) SAML is a spec¬ 
ification describing a set of security assertions that are encoded 
using XML, the request/response protocols used to obtain the 
security assertions, and the bindings of these protocols to various 
transfer protocols (e.g., SOAP, BEEP [Blocks Extensible Ex¬ 
change Protocol], HTTP, etc.). 

security domain A security domain is an environment or context 
that is defined by security policies, security models, and security 
architecture, including a set of resources and set of system en¬ 
tities that are authorized to access the resources. An adminis¬ 
trative domain may contain one or more security domains. The 
traits defining a given security domain typically evolve over time. 

security policy A security policy is a set of rules and practices that 
specify or regulate how a system or organization provides secur¬ 
ity services to protect resources. Security policies are components 
of security architectures. Significant portions of security policies 
are implemented via security services, using security policy ex¬ 
pressions. 

security service A security service is a processing or communi¬ 
cation service that is provided by a system to give a specific kind 
of protection to resources, which may reside with the system or 
with other systems, e.g., an authentication service or a PKI-based 
document attribution and authentication service. Security services 
include authentication, authorization, and accounting (AAA) ser¬ 
vices. Security services typically implement portions of security 
policies, and are implemented via security mechanisms. 

* trademark or registered trademark of Sun Microsystems, Inc. 
or the Object Management Group. 
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